The present invention relates to digital computer systems, and more particularly to a communication protocol used between a central processing unit of a computer and a peripheral device.
A digital computer system consists of a set of functional components of at least three basic types: memory units, input/output (I/O) devices, and central processing units (CPUs). Memory units provide storage for binary data, typically organized as N words each having M bits. Each word in a memory unit is assigned a unique numerical address (O,1, . . . , N-1). The set of all addresses assigned to the memory units in a computer system defines that system's memory address space. The maximum size of a system's memory address space is limited by the number of bits in the addresses identifying unique memory locations. For example, if each address in a computer system consists of ten bits, 2.sup.10 unique locations can be specified. Memory words can be written or read by other components in the computer system.
I/O modules are functionally similar to memory modules, in that they can support both read and write operations. An I/O module usually consists of an I/O device and a device controller. Floppy and hard disk drives, tape drives, printers, display screens, CD ROMs, and modems are all examples of I/O devices. A device controller functions to receive commands and data from other system components, and causes the I/O device to operate in accordance with those commands. Unique addresses can be assigned to each word of data stored in or provided by an I/O module. The set of addresses available for assignment to I/O modules in a system defines that system's I/O address space, the size of which is limited only by the number of bits used to specify an I/O address.
CPUs are typically the focal point of activity in a computer system. A CPU reads instructions and data from memory or from I/O devices, performs logical or arithmetic manipulations on data as directed by instructions, and writes data to memory or to I/O modules after processing.
A growing trend in computer systems design has been to utilize the techniques of virtual memory management in order to increase the effective memory address space of a computer system to be as large as the addressing capability of the CPU, even though the actual memory physically present is much less. In one typical way of using virtual memory techniques the storage facilities provided by I/O modules merged with the memory address space to form a larger "virtual memory space". In this way, using "swapping", the storage facilities of magnetic disks or the like can be used to provide a very large memory space for the processing unit at a cost that is significantly less than if the same size memory space was implemented with costly RAM devices.
The time required to access (read or write) a particular location in a peripheral storage device is typically much slower than the access time for a location in a RAM OR ROM memory unit. Thus, in order for peripheral storage devices to be useful, either in providing conventional bulk storage or in providing a larger virtual memory space for the system, these devices must be very efficient, providing the fastest possible access to the stored information.
The channel of communication of digital information between the various components which comprise a computer system is commonly provided in the form of a collection of electrically conductive lines called a bus. In many systems, a single bus connects each of the system components together, and access to the bus is shared among all components which may require it. A system bus typically includes lines which carry addresses (either I/O space addresses or memory space addresses), lines which carry data, and lines which carry control information. The format and timing of address, data and control information as it is passed along a shared bus is called the bus protocol. A number of different bus protocols have been previously used. In order for a module to communicate with other components in a system, the module should have a bus interface residing between the module and the shared system bus which enables the module to communicate vie the system bus in a manner that conforms to the specified bus protocol.
In the case of I/O modules, the system bus interface receives information from the bus in the specified bus format and passes this information to the I/O controller. The I/O controller then translates this information into a format that is appropriate for the I/O device that it controls, and causes the I/O device to perform the function specified as part of the information passed to the I/O module. Standard protocols are known for coordinating the communication between an I/O controller and an I/O device, just as there are various protocols for specifying communication between the I/O controller and other system components on the shared system bus.
One method for implementing the interface between a processor and an I/O module is to "map" the I/O module in the I/O space of the processor; that is, certain addresses in the I/O space of the processor are reserved for use by a particular I/O module. When data on the system bus is addressed to these reserved locations, the I/O module's bus interface can decode the address on the system bus and identify the corresponding data as being sent to that I/O module. The I/O controller thus intercepts the data and control information sent to it, and causes the I/O device to operate accordingly.
Various types of disk drive controllers are discussed in articles puplished in PC Week, Aug. 22, 1988, pp. 59, 60 and 64. For example, single-user DOS-based systems have predominantly used a controller card and separate drives, with an industry-standard "ST506" interface. Another alternative for disk drive interface is the "Small Computer System Interface" or "SCSI" method.
The CP-341 disk drive manufactured by Conner Peripherals, Inc., is an example of an I/O module which employs an I/O mapped register interface between the controller and the system processor. The CP-341 is an "integrated" drive, referring to the fact that the single unit incorporates both the disk drive device and the controller hardware. The embedded CP-341 controller provides a set of ten registers that are mapped into the I/O space of the host system. These registers, which comprise the software interface between the host and the controller, each have a statically defined function and are accessed through I/O read and write instructions executed by the processor. The CP-341 controller receives data and commands via these registers, and converts this information into the primitive control instructions comprehensible to the disk drive itself. The system processor, in turn, receives status information, error codes and data from the drive via the same registers. The integrated CP-341 drive facilitates processor access to the I/O mapped registers via a precisely defined set of control signal lines, which comprise the hardware interface between the processor and the controller. Together, the hardware and software interfaces implemented by the CP-341 conform to what has become a defacto industry standard protocol.
The register set software interface employed by the CP-341 and other so-called "Industry Standard Architecture" (ISA) integrated drives is limiting in the sense that disk driver software executed by the system processor must communicate with the drive using only the ten registers described above, regardless of the software's capabilities and command structures, or of the potential for enhanced functionality on the part of the drive. More comprehensive, "intelligent" disk driving software or disk drives could potentially require the communication of additional control and status information between the processor and the drive module. Such information, along with the parameter and status words already included in the definition of the CP-341's register set could easily overflow the I/O mapped register space provided under this protocol. This additional information includes: specification of specialized formatting parameters, such as variable numbers of sectors per track, variable sector size, unique ID bytes, gap lengths, or data fill patterns; specification of seek operation parameters, such as alternate disk seek optimization algorithms; specification of alternate buffering and caching algorithms; enhanced error detection and correction information, including detailed error history reports, specification of retry parameters; specification of data encryption algorithms, data compaction algorithms, or defect management algorithms; specification and reporting of diagnostic tests; or specification of additional opcodes and commands not defined in the standard protocol. Clearly, the transfer of some or all of this additional information between the host processor and the I/O module at command entry or command completion could not efficiently be accomplished using only the ten registers specified in the standard protocol.
An alternative to the conventional register set software interface is a "block-transfer" protocol, previously known, which overcomes many of the limitations of a dedicated I/O mapped register interface, allowing a computer system to exploit additional functionality on the part of either the disk drive itself, the operating system disk driving software, or both. This "block-transfer" type of interface protocol specifies that configuration, status, and parameter information, as well as data, be transferred across the host/peripheral interface in the form of multiple-word information blocks, rather than in the single-word formats of conventional I/O mapped register set interfaces. Various block-transfer interface protocols have been previously disclosed, examples being the so-called PS/2 ESDI or ST506 protocols. Typically, a block-transfer protocol specifies that registers similar to the I/O mapped registers of conventional register set interfaces be provided for coordinating the transfers of blocks of information, while the information blocks themselves are transferred using techniques of direct memory access (DMA) or other high-speed transfer methods.
Block-transfer interface protocols have an advantage over register set protocols in that each of the various information block formats can be defined to hold as much information as the disk drive or disk driving software requires. Whereas in register set interfaces, for example, status information is passed from the disk drive to the host via a single word in a "status register", with a block-transfer protocol a multiple-word status "block" can be defined which holds as much status information about the disk drive as desired. Likewise, configuration information, error detection/correction information, drive parameter information or other control or diagnostic information can be transferred between host and peripheral in blocks which are as large or small as necessary to suit the disk drive and disk driving software.
It is accordingly an object of the present invention to provide a disk drive which offers the versatility of block-transfer information exchange. It is a further object of this invention to provide a disk drive which is mode-selectable such that it can also support conventional I/O mapped register set communication with a host processor. Yet another object of the present invention is to provide a disk drive which conforms to the hardware interface specified for the standard register set interface protocol, but which can be applied in systems having one of a wide range of different disk drivers or bus definitions, without requiring modifications to the drive programming or electrical interface. Using a drive which conforms to the present invention, therefore, allows disk drivers the flexibility to send and receive information in almost any format.